1. Field of the Invention
This invention is directed to a telecommunications management system and more particularly to a telemanagement system having single point of entry and synchronized database features.
2. Description of the Prior Art
As technology continues to march forward year after year, the telecommunications professional is faced with an ever increasingly complex task of dealing with these systems. In the early days (circa 1982-85), a corporation""s telecommunications infrastructure typically consisted of only a single phone system using a single Public Broadcast Exchange (PBX). When a new employee came aboard, maintenance on this system was relatively simplexe2x80x94a few commands was all that was required to add a new phone.
However, as corporations grew, so did their phone systems. Soon, companies had multiple systems scattered among several sites. When an employee moved from one site to another more commands were needed to accomplish this taskxe2x80x94a xe2x80x9cdeletexe2x80x9d on the old system and an xe2x80x9caddxe2x80x9d on the new system.
Telecommunication professionals invented new ways in dealing with these changes. By using change requisition forms and control sheets, the work could be managed and processed in bulkxe2x80x94all manually. This technique workedxe2x80x94for a while.
For years, the only way to get reports on a corporation""s phone activity was to wait for the bill from the phone company. However, soon the owners of these systems realized they too could track phone activity by using special data ports in the PBX. These ports became known as Station Message Detail Records or SMDR. The concept was simplexe2x80x94every time a phone call was completed, the PBX would transmit a single SMDR data packet. These data packets could be collected, stored on a computer, and detailed reports could be generated. A new system known as Call Accounting was introduced to meet this requirement.
However, Call Accounting systems also required their own data management. When a new employee came aboard, the telecommunications professional had to add a data record into the Phone System and into the Call Accounting system as well. When an employee moved, multiple records and multiple systems needed updating. But technology did not stop there. Soon corporations began replacing individual telephone answering devices with more economical Voice Mail Systems (VMS). These systems could literally replace thousands of individual answering devices with a single machine. However, these systems needed data management as well. With the introduction of Computer-Based Phone Directories, Human Resource Systems, Credit Card/Authorization Code Systems, Emergency 911 Systems, Service Billing Systems, Network Access Devices, and many others, the telecommunications professional was soon faced with updating as many as 10 (or more) separate systems with the exact same information. Even with forms and procedures, this task was difficult at best and very error prone. obviously, a better method was needed.
The professional had to wait until the early 90""s before solutions were attempted to address this problem. The first attempt at solving this problem was known as product integration. The concept was simple, a telecommunications vendor would produce a product that would combine all of the needed features into a single package. By having all of the telecommunication systems in a single platform, software could be engineered to share a single database. This would allow a single data management screen to be presented to the telecommunication professional. From this screen, all products could be updated at once. Soon, products began appearing on the market that were Call Accounting+Voice Mail+Phone Directory (or the like) all in one software package. North Coast Logic produced two generations of such packages (VSX and ARENIX). These packages worked in many environments and are still in use today.
However, they didn""t work in all situations. One problem was many corporations wanted multi-vendor solutions. The telecommunications"" professional did not want to be dependent on single vendor for the entire communications infrastructure. They wanted to shop and get the best value. They also soon realized that a single vendor could not be an expert in every industry.
Another problem was that these integrated products typically consisted of a single hardware platform. All applications ran on a single machine. If that machine failed, the entire infrastructure was brought down. Even though many vendors tried to compensate for this by using highly reliable (and redundant) equipment, the solution still fell short of relieving the mounting workload on the professional.
The problem with a single database design became evident by the database technology itself. No single database technology fills every application requirement. Each vendor makes database technology decisions based on their unique system framework. For example, a Call Accounting system may be able to use any off the shelf Database Management System (DBMS), but a Voice Mail System needs a specialized data streaming system that is able to store and retrieve recorded voice data at 4-8 kb per second. A Phone System database is usually completely stored in memory and made up of a series of jump tables organized in a tree-like fashion. This allows the system to traverse the database as each digit is dialed. No off the shelf database product would fit all of these unique requirements.
In addition to the problems described above, an even worse issue exists with these early integrated systems. In a typical telecommunications environment, each of these systems have their own data entry terminal. This means that if the telecommunications professional does not use the integrated data management screen to do updates, the various databases in each system will become out-of-sync with each other. This is known as the multiple-entry problem.
For example, suppose that the telecommunications professional updates the phone system via its own data entry terminal, but updates the Call Accounting and Phone Directory via the integrated data management screen. In this scenario, it is possible that the changes made directly to the PBX may be lost or be left different than those in the integrated product. The two databases are out-of-sync.
Although it is tempting to mandate that all data entry is done via the integrated screen, in practice this is seldom the case. In many situations, work is required to be performed on a specific system and may require the use of a special field not accessible via the integrated screen. Even if all features could be moved to the integrated data management screen, the user interface would be so unwieldy that no user could navigate it.
The solution to this problem is a new telecommunications management system that deploys a unique Single-Point-of-Entry and Synchronous Data Base system that addresses the shortcomings of the prior art.
The system of the present invention is an integrated suite of system control and application software modules used to manage one or more telephone systems. In addition to controlling commonly used PBX systems, the invention controls adjunct systems such as voice mail and 911 emergency systems. The system of the invention ties its application modules and system control modules together through a single point of entry and a synchronized database. Information entered through one module is automatically accessible by all other modules. Details of the various application modules are described in more detail in copending U.S. patent application Ser. No. 09/183,414, filed Oct. 30, 1998 by the same inventor and assigned to the same assignee as the present application, the entire application of which is hereby incorporated by reference herein.
Repeated data entry and multiple system management are eliminated for client application such as call accounting, cabling, assets, work orders, trouble tickets, traffic analysis, authorization codes, bill reconciliation, billing and other applications. The system ties its modules together across a LAN or operates as a stand-alone system. Operators can use networked computers for number lookup on its interactive directory or for information distribution via its message center.
The telemanagement system of the present invention is created around several concepts. First, modules are easily added to suit a company""s growing needs. As technology advances, the system provides seamless integration between the PBX, the voice mail, and each existing, or Suture module.
Second, the system easily synchronizes several databases, allowing them to operate as one. It is impractical to manage multiple applications and devices with a single database. Technicians are comfortable with PBX and voice mail programming. Requiring them to relearn system programming through a new interface can jeopardize system stability. The system of the present invention reaches out to the PBX and the voice mail databases and adjusts them by reading from or writing to them. Users can synchronize records one at a time or all together. A reconciliation feature compares databases and makes changes where deemed appropriate.
The modular design and database synchronization establish the foundation for the system design of Single Point of Entry (SPE). Single point of entry eliminates the need to actively manage multiple systems. Instead of entering changes into each telemanagement application, information is shared between the modules and automatically updated with each move, add, or change. Default information can often be used to fill in fields and further reduce entry time.
Single point of entry is how the present invention distributes data entered in one module to all other modules. The system communicates to its application modules, the PBX system, the voice mail and other adjunct systems via communication links, then translates or transfers the data so that it can be used as necessary.
The modules that control the PBX and the adjunct systems are referred to as SPEs. Using a PBX SPE, a user can make PBX moves, adds, and changes then quickly move to an application such as call accounting. Any change made in one module can immediately be learned by the others. This makes adding a new user as easy as making a few mouse clicks.
Using a combination of system control and application modules, the user can add a station, commit inventory, execute system programming commands, reserve cable pairs, update directory information, determine associated costs, and bill accounts-all through a single user interface.
SPEs address the many databases maintained by a telecommunication-department. In addition to supporting the PBX and network hardware, it is common for an administrator to have to modify or update multiple files, systems, databases, and records. These updates may include PBX maintenance, voice mail administration, and emergency 911 demographics.
In the telemanagement system of the present invention, a Client Application can request a service to be performed by a Service Provider. A Client Application is a telemanagement application program providing management features such as Call Accounting, Cable Plant Tracking, etc. A Service Provider is software program that allows management of the PBX telephone system and adjunct systems such as a voice mail and 911 emergency systems.
The problem in the telecommunications world is that no single data management standard exists which would allow one to write a single, generic Service Provider. Previously each Service Provider had to be designed to interact with each system differently. However, all Service Providers had to provide the appearance of having homogeneous data representation across all systems.
To accomplish this xe2x80x9cillusionxe2x80x9d, the telemanagement system of the present invention represents a specific data field on a specific system as a unique property. A property has the following attributes:
Human-readable namexe2x80x94used for identifying this property to the user.
Field namexe2x80x94suitable for database use and SQL syntax.
Read/Write Access flagsxe2x80x94used to indicate whether this system supports modifications to this field. Valid selections are read-only, write-only, read-write.
Lengthxe2x80x94used to limit data entry to this property.
Categoryxe2x80x94used for placing properties into groups for easier management.
Default Valuexe2x80x94a specially encoded string that allows the Service Provider to extract data from other parts of the telemanagement system.
By using this property technique, the Service Provider assumes the role of a translator. It converts the homogeneous data view into system specific information and visa-versa.
In addition to abstracting the individual properties, the number and type of properties are abstracted as well. This abstraction allows the client software in the telemanagement system to interrogate the Service Provider for the supported properties. This interrogation is handled by a protocol known as SPE configuration. When the telemanagement system software is first installed, the user can use system setup features to configure each SPE, and customize each one for their use. This allows the user to manage just the properties that are important to a particular installation and not the entire property set for all installed Service Providers. Thus, the skill level of the end-user, not the software developer, determines the complexity of the user-interface.
The SPE Configuration protocol uses a series of info data packets to accomplish the interrogation.
Once the Service Provider sends a list of all supported properties, the Client software can display a configuration dialog. This dialog allows the user to configure the properties to be managed. When the user has included/excluded the desired properties, a Create Table button is pressed. This instructs the telemanagement system to use the selected property fields to build a master database table. This table contains a master copy of the data in the PBX or adjunct system in its xe2x80x9chomogeneousxe2x80x9d form. This allows the data to be shared with other PBX or adjunct systems.
Since the end-user has control over which properties of each system are to be managed, the system provides for the dynamic generation of the user interfaces. In addition, the user-interface supports data sharing among systems.
The interface was split into two sections, a user-record selection part, and a Service Provider access part. A list of all managed users is displayed on the left-hand side, while a tab is displayed on the right-hand side for each Service Provider active in the system
This design maintains the appearance of one master user database, which could access any Service Provider in the system. In addition, when a new Service Provider is added into the environment, only a new tab appears. No data has to be copied, or tables have to be converted to maintain this single database appearance. To access a particular Service Provider, the end-user need only select the appropriate user record, and click on the tab of the system that needs to be managed.
If the end-user has not configured any properties for a particular system, then its corresponding tab is not displayed. Thus the complexity of the user-interface can be managedxe2x80x94unnecessary fields are effectively hidden.
The end-user has a convenient interface in which to control the Master Database and interact with the PBX and adjunct systems. In addition, this design allows the user to build-up the master database offline from the these systems.
Having separate control of the master data base and the Service Provider is an important aspect of the system in providing efficient data management.
Of course, having two independent controls allows for possible database synchronization problems. This especially becomes evident when you add a PBX Maintenance terminal. Data entered by the PBX Maintenance Terminal will not be automatically entered into the Master Database. In addition, it is possible to enter data into the Master Database without sending the changes to the PBX or adjunct systems. This is called delayed update. If either of these conditions exist, the master database is out-of-sync with the these systems.
To overcome this problem, the telemanagement system of the present invention deploys the Service Provider control called Learn. This control allows the end-user to perform a one-record synchronization between the Master Database and the PBX and adjunct systems.
By using the Learn control, the end-user can immediately query the PBX or adjunct system for any changes that were made outside the telemanagement system. In fact, the end-user can check these systems to see if the record even exists at all. If is does, all data regarding this user is retrieved and inserted into the Master Database thus eliminating any data entry. Since the synchronization is for only the selected user record, synchronization occurs in real-time and is typically 1-2 seconds.
By using the Learn Control, Single-Point-of-Entry can be maintained regardless of the existence of multiple databases, and multiple data entry terminals (multiple-points-of-entry).
In addition, Learn can be deployed across all records in the master database and all records in the PBX and adjunct systems. We call this global synchronization. By using global synchronization, the end-user can quickly populate the master database from the these systems, or update the systems with records that were entered offline.
The telemanagement system of the present invention includes an underlying technology providing interprocess communication, called ARENA. The Arena is a real-time messaging system in which all of the various software modules in the telemanagement system can interact.
The request is sent to the Arena and is dispatched to the appropriate Service Provider. The Service Provider performs the request and sends the response back to the Client Application. The return trip of the request is typically a few seconds.
All the software in the telemanagement system communicates in this manner. Each message sent through the Arena is referred to as an event. The data contained in each message is typically human-readable text. A method of encoding data into human-readable strings that are prepared for transmission is used. When received, the strings are decoded back into application specific data structures and processed. Since each packet is encoded/decoded in this manner, Arena messages are able to traverse various operating systems and heterogeneous networking environments.
The telemanagement system can have many Service Providers, so the system requires a routing/group provider technology in the Arena. This would allow many telemanagement systems to talk to many Service Provider Modules.
To accomplish this, the present system deploys a method of subscribing/unsubscribing to particular Arena events. Every message sent through the Arena contains a 4-character event name. When a Service Provider initializes, it makes itself known to the Arena by connecting and subscribing to a particular event by using the event name.
This mechanism provides the means of routing an event through the Arena system to a particular Service Provider. But this routing has important side benefit: all Client requests for a particular Service Provider can be grouped together.
Grouping provides traffic efficiency but requires another mechanism in the Arena environmentxe2x80x94Peer-to-Peer messaging. If two clients are requesting a service to be performed from the same Service Provider, the Service Provider receives both message packets and can perform the work efficiently (i.e. bulk the requests). However, the results of each request must be sent back only to each requester. To accomplish this the present system deploys a modified RPC (remote procedure call). A request could be received in a broadcast scenario but responded to individually by the Service Provider.